Шаг 5. Объединяем ветки с использованием режима no-fast-forward

Теперь попробуем сделать слияние с использованием режима no-fast-forward. Снова переключимся на ветку develop с помощью команды git switch develop.

Ещё раз внесём изменение. Создадим директорию css и добавим в неё файл styles.css.

После этого добавим изменение в индекс с помощью команды git add -A.

Далее нам нужно закоммитить изменения с помощью команды git commit -m "feat: added a new styles.css file".

Теперь переключимся назад на ветку main, используя команду git switch -.

Если сейчас посмотрим в корневую директорию, то увидим, что папки css не стало. Это нормально, так как мы добавляли её на ветке develop.

Объединим ветки с использованием режима no-fast-forward.

По умолчанию, если не использовать опцию -m, Git сам напишет коммит в стиле Merging with develop. Нас это не устраивает, поэтому мы будем использовать опцию -m, чтобы самостоятельно написать коммит.

Введём команду git merge --no-ff develop -m "feat: the develop branch is merged into the main branch".

Слияние прошло успешно, без конфликтов.

В выводе есть строчка Merge made by the 'ort' strategy. Помимо режимов слияния, в Git есть ещё и стратегии слияния. Они указывают, как должно происходить слияние.

Стратегия ort установлена по умолчанию при использовании режима no-fast-forward. Она расшифровывается как Ostensibly Recursive’s Twin, что означает рекурсивный двойник. Раньше по умолчанию использовалась стратегия recursive, но потом было решено заменить на другой алгоритм — как раз таки ort.

В статье про режимы сливания мы рассказывали, что коммит слияния является дочерним по отношению к двум другим коммитам — которые были последними до появления коммита слияния. Так вот, данная стратегия позволяет взаимодействовать только с двумя родительскими коммитами, используя трёхсторонний алгоритм слияния. Сначала этот алгоритм делает проверку. Если существует больше одного родительского коммита, которые можно использовать для трёхстороннего слияния, то алгоритм создаёт объединённое дерево из этих родительских коммитов и использует его в качестве дерева, содержащего ссылки для трёхстороннего слияния.

Вернёмся в редактор кода и посмотрим, появилась ли директория css с файлом styles.css после слияния.

Директория появилась, всё прошло хорошо. Дополнительно проверим список коммитов с помощью команды git log --oneline.

Появился и коммит слияния, и коммит, который мы создавали на ветке develop.

Далее снова отправим изменения со всех веток с помощью команды git push --all.

Изменения отправлены в удалённый репозиторий.

Сейчас ветка develop находится позади ветки main, так как в ней нет коммита слияния, который присутствует на ветке main. Чтобы в будущем не возникало проблем с отправкой изменений в удалённый репозиторий, мы сейчас удалим ветку, а затем снова её создадим. Можно было бы просто сделать копию коммита, но это тема другой демонстрации.

Пропишем команду из ветки main — git branch --delete develop.

Теперь удалим ветку в удалённом репозитории с помощью команды git push --delete origin develop.

Всё, ветки больше не существует. Для проверки выполним команду git branch --all, чтобы узнать, какие существуют ветки в локальном и удалённом репозиториях.

Все упоминания о ветке develop стёрты. Далее заново её создадим с помощью команды git switch --create develop.

Последнее, что нам осталось сделать — отправить ветку в удалённый репозиторий с помощью команды git push --set-upstream origin develop.

Теперь ветка develop идентична ветке main.